GAUD-10597 - Add drag test command - #1069
Conversation
| } | ||
|
|
||
| export async function dragElemBy(elem, offsetX = 0, offsetY = 0) { | ||
| const pixels = 10; // Mimic dragging by moving in 10px increments to the target position |
There was a problem hiding this comment.
I want to simulate a user actually dragging something, which fires events every few pixels. Just moving from one place to another programmatically doesn't fire any intermediate values.
I'm firing every 10px, but this could also just break up the values passed into 5 steps of x pixels. That's likely better for large numbers, whereas this is better for small number (eg not bothering to divide a move of 2 pixels).
There was a problem hiding this comment.
Nit: maybe call this something like dragIncrementSize?
| await sendMouse({ type: 'up' }); | ||
| } | ||
|
|
||
| export async function dragElemBy(elem, offsetX = 0, offsetY = 0) { |
There was a problem hiding this comment.
Name is a little odd. I'm trying to follow the pattern of the other helpers in this file, taking x and y offsets as parameters. They work a little differently though, and use "at" terminology, which doesn't make sense here.
But dragElemTo isn't correct, unless I take an x and y location rather than an offset. This is nicer for the helper, worse for the consumer - it's much easier if I can say "Drag it back 5 pixels" instead of "Drag it to spot x = 250".
| await sendMouse({ type: 'up' }); | ||
| } | ||
|
|
||
| export async function dragElemBy(elem, offsetX = 0, offsetY = 0) { |
| } | ||
|
|
||
| export async function dragElemBy(elem, offsetX = 0, offsetY = 0) { | ||
| const pixels = 10; // Mimic dragging by moving in 10px increments to the target position |
There was a problem hiding this comment.
Nit: maybe call this something like dragIncrementSize?
| const dy = Math.sign(offsetY) * Math.min(Math.abs(offsetY), pixels * i); | ||
| await sendMouse({ type: 'move', position: [position.x + dx, position.y + dy] }); | ||
| } | ||
| await sendMouse({ type: 'up' }); |
There was a problem hiding this comment.
Just to confirm: I'm assuming there's something already that'll release the mouse in between tests, just in case this aborts partway through?
There was a problem hiding this comment.
Good callout - we actually don't. @web/test-runner-commands has a resetMouse command that moves it back to (0,0) and releases buttons, but we don't use it. We just do the move ourselves. Been like that since the get-go and no clues in the PR discussion.
There was a problem hiding this comment.
This is what @web/test-runner-commands's does, I think we just try to use it...
There was a problem hiding this comment.
Oh cool, yeah let's try using that!
There was a problem hiding this comment.
After this PR merges, I'll check test run times and see if it makes a huge difference. I don't think it will, since we only reset the mouse if we've touched it.
There was a problem hiding this comment.
Ok, I don't think we can use resetMouse. I'm running into this issue: modernweb-dev/web#2085. When --watching in Chromium, every time the mouse is reset, the context menu is opened and stays open for the next test (unless you click to close it, and interfere with the test). Doesn't matter if you have devTools open or not.
I think we just do it ourselves until this is fixed, and only bother with the left button, since we don't expose any commands that press the middle or right buttons anyways.
There was a problem hiding this comment.
I'm going to do this in a separate PR, that also adds the ability to not complete the drag.
|
🎉 This PR is included in version 1.51.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
2 participants
Not really tied to how this works at all, so figured I'd get it up and get feedback rather than trying to keep tweaking it.